home *** CD-ROM | disk | FTP | other *** search
/ PC World Komputer 2010 April / PCWorld0410.iso / redakcyjne / programy / Tlen 6.0.1.12 pl / tleninst60112.exe / sdk / Plugin_src / basic-vc / AggressiveOptimize.h next >
C/C++ Source or Header  |  2006-09-18  |  9KB  |  167 lines
  1.  
  2. //////////////////////////////
  3. // Version 1.40 
  4. // October 22nd, 2002 - .NET (VC7, _MSC_VER=1300) support!
  5. // Version 1.30
  6. // Nov 24th, 2000
  7. // Version 1.20
  8. // Jun 9th, 2000
  9. // Version 1.10
  10. // Jan 23rd, 2000
  11. // Version 1.00
  12. // May 20th, 1999
  13. // Todd C. Wilson, Fresh Ground Software
  14. // (todd@nopcode.com)
  15. // This header file will kick in settings for Visual C++ 5 and 6 that will (usually)
  16. // result in smaller exe's.
  17. // The "trick" is to tell the compiler to not pad out the function calls; this is done
  18. // by not using the /O1 or /O2 option - if you do, you implicitly use /Gy, which pads
  19. // out each and every function call. In one single 500k dll, I managed to cut out 120k
  20. // by this alone!
  21. // The other two "tricks" are telling the Linker to merge all data-type segments together
  22. // in the exe file. The relocation, read-only (constants) data, and code section (.text)
  23. // sections can almost always be merged. Each section merged can save 4k in exe space,
  24. // since each section is padded out to 4k chunks. This is very noticeable with smaller
  25. // exes, since you could have only 700 bytes of data, 300 bytes of code, 94 bytes of
  26. // strings - padded out, this could be 12k of runtime, for 1094 bytes of stuff! For larger
  27. // programs, this is less overall, but can save at least 4k.
  28. // Note that if you're using MFC static or some other 3rd party libs, you may get poor
  29. // results with merging the readonly (.rdata) section - the exe may grow larger.
  30. // To use this feature, define _MERGE_DATA_ in your project or before this header is used.
  31. // With Visual C++ 5, the program uses a file alignment of 512 bytes, which results
  32. // in a small exe. Under VC6, the program instead uses 4k, which is the same as the
  33. // section size. The reason (from what I understand) is that 4k is the chunk size of
  34. // the virtual memory manager, and that WinAlign (an end-user tuning tool for Win98)
  35. // will re-align the programs on this boundary. The problem with this is that all of
  36. // Microsoft's system exes and dlls are *NOT* tuned like this, and using 4k causes serious
  37. // exe bloat. This is very noticeable for smaller programs.
  38. // The "trick" for this is to use the undocumented FILEALIGN linker parm to change the
  39. // padding from 4k to 1/2k, which results in a much smaller exe - anywhere from 20%-75%
  40. // depending on the size. Note that this is the same as using /OPT:NOWIN98, which *is*
  41. // a previously documented switch, but was left out of the docs for some reason in VC6 and
  42. // all of the current MSDN's - see KB:Q235956 for more information.
  43. // Microsoft does say that using the 4k alignment will "speed up process loading",
  44. // but I've been unable to notice a difference, even on my P180, with a very large (4meg) exe.
  45. // Please note, however, that this will probably not change the size of the COMPRESSED
  46. // file (either in a .zip file or in an install archive), since this 4k is all zeroes and
  47. // gets compressed away.
  48. // Also, the /ALIGN:4096 switch will "magically" do the same thing, even though this is the
  49. // default setting for this switch. Apparently this sets the same values as the above two
  50. // switches do. We do not use this in this header, since it smacks of a bug and not a feature.
  51. // Thanks to Michael Geary <Mike@Geary.com> for some additional tips!
  52. //
  53. // Notes about using this header in .NET
  54. // First off, VC7 does not allow a lot of the linker command options in pragma's. There is no
  55. // honest or good reason why Microsoft decided to make this change, it just doesn't.
  56. // So that is why there are a lot of <1300 #if's in the header.
  57. // If you want to take full advantage of the VC7 linker options, you will need to do it on a 
  58. // PER PROJECT BASIS; you can no longer use a global header file like this to make it better.
  59. // Items I strongly suggest putting in all your VC7 project linker options command line settings:
  60. //            /ignore:4078    /RELEASE
  61. // Compiler options:
  62. //            /GL (Whole Program Optimization)
  63. // If you're making an .EXE and not a .DLL, consider adding in:
  64. //            /GA (Optimize for Windows Application)
  65. // Some items to consider using in your VC7 projects (not VC6):
  66. // Link-time Code Generation - whole code optimization. Put this in your exe/dll project link settings.
  67. //            /LTCG:NOSTATUS
  68. // The classic no-padding and no-bloat compiler C/C++ switch:
  69. //            /opt:nowin98
  70. //
  71. // (C++ command line options:  /GL /opt:nowin98  and /GA for .exe files)
  72. // (Link command line options: /ignore:4078 /RELEASE /LTCG:NOSTATUS)
  73. //
  74. // Now, notes on using these options in VC7 vs VC6.
  75. // VC6 consistently, for me, produces smaller code from C++ the exact same sources,
  76. // with or without this header. On average, VC6 produces 5% smaller binaries compared
  77. // to VC7 compiling the exact same project, *without* this header. With this header, VC6
  78. // will make a 13k file, while VC7 will make a 64k one. VC7 is just bloaty, pure and
  79. // simple - all that managed/unmanaged C++ runtimes, and the CLR stuff must be getting
  80. // in the way of code generation. However, template support is better, so there.
  81. // Both VC6 and VC7 show the same end kind of end result savings - larger binary output
  82. // will shave about 2% off, where as smaller projects (support DLL's, cpl's,
  83. // activex controls, ATL libs, etc) get the best result, since the padding is usually
  84. // more than the actual usable code. But again, VC7 does not compile down as small as VC6.
  85. //
  86. // The argument can be made that doing this is a waste of time, since the "zero bytes"
  87. // will be compressed out in a zip file or install archive. Not really - it doesn't matter
  88. // if the data is a string of zeroes or ones or 85858585 - it will still take room (20 bytes
  89. // in a zip file, 29 bytes if only *4* of them 4k bytes are not the same) and time to
  90. // compress that data and decompress it. Also, 20k of zeros is NOT 20k on disk - it's the
  91. // size of the cluster slop- for Fat32 systems, 20k can be 32k, NTFS could make it 24k if you're
  92. // just 1 byte over (round up). Most end users do not have the dual P4 Xeon systems with
  93. // two gigs of RDram and a Raid 0+1 of Western Digital 120meg Special Editions that all
  94. // worthy developers have (all six of us), so they will need any space and LOADING TIME
  95. // savings they will need; taking an extra 32k or more out of your end user's 64megs of
  96. // ram on Windows 98 is Not a Good Thing.
  97. //
  98. // Now, as a ADDED BONUS at NO EXTRA COST TO YOU! Under VC6, using the /merge:.text=.data
  99. // pragma will cause the output file to be un-disassembleable! (is that a word?) At least,
  100. // with the normal tools - WinDisam, DumpBin, and the like will not work. Try it - use the
  101. // header, compile release, and then use DUMPBIN /DISASM filename.exe - no code!
  102. // Thanks to Gδzim Pani <gpani@siu.edu> for discovering this gem - for a full writeup on
  103. // this issue and the ramifactions of it, visit www.nopcode.com for the Aggressive Optimize
  104. // article.
  105.  
  106. #ifndef _AGGRESSIVEOPTIMIZE_H_
  107. #define _AGGRESSIVEOPTIMIZE_H_
  108.  
  109. #pragma warning(disable:4711)
  110.  
  111. #ifdef NDEBUG
  112. // /Og (global optimizations), /Os (favor small code), /Oy (no frame pointers)
  113. #pragma optimize("gsy",on)
  114.  
  115. #if (_MSC_VER<1300)
  116.     #pragma comment(linker,"/RELEASE")
  117. #endif
  118.  
  119. // Note that merging the .rdata section will result in LARGER exe's if you using
  120. // MFC (esp. static link). If this is desirable, define _MERGE_RDATA_ in your project.
  121. #ifdef _MERGE_RDATA_
  122. #pragma comment(linker,"/merge:.rdata=.data")
  123. #endif // _MERGE_RDATA_
  124.  
  125. #pragma comment(linker,"/merge:.text=.data")
  126. #if (_MSC_VER<1300)
  127.     // In VC7, this causes problems with the relocation and data tables, so best to not merge them
  128.     #pragma comment(linker,"/merge:.reloc=.data")
  129. #endif
  130.  
  131. // Merging sections with different attributes causes a linker warning, so
  132. // turn off the warning. From Michael Geary. Undocumented, as usual!
  133. #if (_MSC_VER<1300)
  134.     // In VC7, you will need to put this in your project settings
  135.     #pragma comment(linker,"/ignore:4078")
  136. #endif
  137.  
  138. // With Visual C++ 5, you already get the 512-byte alignment, so you will only need
  139. // it for VC6, and maybe later.
  140. #if _MSC_VER >= 1000
  141.  
  142. // Option #1: use /filealign
  143. // Totally undocumented! And if you set it lower than 512 bytes, the program crashes.
  144. // Either leave at 0x200 or 0x1000
  145. //#pragma comment(linker,"/FILEALIGN:0x200")
  146.  
  147. // Option #2: use /opt:nowin98
  148. // See KB:Q235956 or the READMEVC.htm in your VC directory for info on this one.
  149. // This is our currently preferred option, since it is fully documented and unlikely
  150. // to break in service packs and updates.
  151. #if (_MSC_VER<1300)
  152.     // In VC7, you will need to put this in your project settings
  153.     #pragma comment(linker,"/opt:nowin98")
  154. #else
  155.  
  156. // Option #3: use /align:4096
  157. // A side effect of using the default align value is that it turns on the above switch.
  158. // Does nothing under Vc7 that /opt:nowin98 doesn't already give you
  159. // #pragma comment(linker,"/ALIGN:512")
  160. #endif
  161.  
  162. #endif // _MSC_VER >= 1000
  163.  
  164. #endif // NDEBUG
  165.  
  166. #endif //  _AGGRESSIVEOPTIMIZE_H_
  167.